The invention finds application notably in small-area displays found on portable or console electrical devices. Numerous such devices exist, such as PDAs, cordless, mobile and desk telephones, in-car information consoles, hand-held electronic games sets, multifunction watches etc.
In the prior art, there is typically a main CPU, which has the task of receiving display commands, processing them and sending the results to the display module in a pixel-data form describing the properties of each display pixel. The amount of data sent to the display module is proportional to the display resolution and the colour depth. For example, a small monochrome display of 96×96 pixels with a four level grey scale requires a fairly small amount of data to be transferred to the display module. Such a screen does not, however, meet user demand for increasingly attractive and informative displays.
With the demand for colour displays and for sophisticated graphics requiring higher screen resolution, the amount of data to be processed by the CPU and sent to the display module has become much greater. More complex graphics processing places a heavy strain on the CPU and slows the device, so that display reaction and refresh rate may become unacceptable. This is especially problematic for games applications. Another problem is the power drain caused by increased graphics processing, which can substantially shorten the intervals between recharging of battery-powered devices.
In the rather different technical area of personal computers and computer networks, the problem of displaying sophisticated graphics at an acceptable speed is often solved by a hardware graphics engine (also known as a graphics accelerator) on an extra card that is housed in the processor box or as an embedded unit on the motherboard. The graphics engine takes over at least some of the display command processing from the main CPU. Graphics engines are specially developed for graphics processing, so that they are faster and uses less power than the CPU for the same graphics tasks. The resultant video data is then sent from the processor box to a separate “dumb” display module.
Known graphics engines used in PCs are specially conceived for large-area displays and are thus highly complex systems requiring separate silicon dies for the high number of gates used. It is impractical to incorporate these engines into portable devices, which have small-area displays and in which size and weight are strictly limited, and which have limited power resources.
Moreover, PC graphics engines are designed to process the types of data used in large-area displays, such as multiple bitmaps of complex images. Data sent to mobile and small-area displays may today be in vector graphics form. Examples of vector graphics languages are MacroMediaFlash™ and SVG™. Vector graphics definitions are also used for many gaming Application Programming Interfaces (APIs), for example Microsoft DirectX and Silicon Graphics OpenGL.
In vector graphics images are defined as multiple complex polygons. This makes vector graphics suited to images that can be easily defined by mathematical functions, such as game screens, text and GPS navigation maps. For such images, vector graphics is considerably more efficient than an equivalent bitmap. That is, a vector graphics file defining the same detail (in terms of complex polygons) as a bitmap file (in terms of each individual display pixel) will contain fewer bytes. The bitmap file is the finished image data in pixel format, which can be copied directly to the display.
A complex polygon is a polygon that can self-intersect and have “holes” in it. Examples of complex polygons are letters and numerals such as “X” and “8” and kanji characters. Vector graphics is, of course, also suitable for definition of the simple polygons such as the triangles that make up the basic primitive for many computer games. The polygon is defined by straight or curved edges and fill commands. In theory there is no limit to the number of edges of each polygon. However, a vector graphics file containing, for instance, a photograph of a complex scene will contain several times more bytes than the equivalent bitmap.
Software graphics processing algorithms are also known, some suitable for use with the high-level/vector graphics languages employed with small-area displays. Some algorithms are available, for example, in “Computer Graphics: Principles and Practice” Foley, Van Damn, Feiner, Hughes 1996 Edition, ISBN 0-201-84840-6.
Known software graphics algorithms use internal dynamic data structures with linked lists and sort operations. All the vector graphics commands giving polygon edge data must be read into the software engine and stored before it starts rendering (generating an image for display from the high-level commands received). The commands for each polygon are stored in a master list of start and end points for each polygon edge. The polygon is drawn scanline by scanline. For each scanline of the display the software selects which polygon edges cross the scanline and then identifies where each selected edge crosses the scanline. Once the crossing points have been identified, the polygon can be filled between them. The size of the master list that can be processed is limited by the amount of memory available in the software. The known software algorithms thus suffer from the disadvantage that they require a large amount of memory to store all the commands for complex polygons before rendering. This may prejudice manufacturers against incorporating vector graphics processing in mobile devices.
It is desirable to overcome the disadvantages inherent in the prior art and lessen the CPU load and data traffic for display purposes in portable electrical devices.